The Internet has traditionally provided support for “best effort” traffic only. That is, traffic will be propagated along a path from a source to a destination depending on the congestion or lack thereof existing at each “hop” (typically a router) along the way. If there is little congestion, the traffic will be propagated quickly. If the path is heavily congested, traffic will be buffered (usually first-in-first-out) at congested locations until propagation is possible, which may substantially delay the traffic. Moreover, there is no way for a sender to know ahead of time whether the desired transmission will succeed or fail. This is because Internet traffic follows a “thread-the-needle” approach, wherein each hop or router knows only about the next hop downstream. If traffic at the next hop is extremely congested, the router will nevertheless attempt to forward traffic thereto without searching for an alternate route around it. If the traffic can't be forwarded within a timeout period, the transmission will fail.
The existing Internet “best effort” design is suitable for low priority traffic where transmission latency is acceptable. However, with the proliferation of new technologies using real time applications such as video conferencing, Internet telephony, and other audio/video (A/V) services, guaranteed quality of service (QoS) with minimal and predetermined transmission latency has become increasingly desired. Such service is not possible with the traditional “best effort” design. Ethernet QoS mechansims to assure AV service packets generated on the Ethernet or Internet are delivered in a timely manner are desired. For native Ethernet/IP traffic, priority based schemes are often used, partially due to their simplicity.
Recently, protocol-based QoS solutions have been attempted. One such solution is Resource Reservation Protocol (RSVP), which is an application layer protocol. RSVP is described in R. Braden et al., “Resource ReSerVation Protocol (RSVP)—Version 1 Functional Specification,” RFC 2205, September 1997. Presently, RSVP must be implemented in advanced routers at each hop along the path between sender and receiver. RSVP is designed for reserving resources along paths stretching across multiple networks. Since it is an application layer protocol, it can not be understood or implemented in layer 2 devices such as switches within a local network that often separate a sender or receiver from their gateways to other networks.
A device and mechanism capable of implementing QoS and reserving bandwidth for establishing a path from a source device to a destination device within a network and for transmitting both reserved, and prioritized packet data from output queues within the device, is desired.